<html>

<head>
<meta charset="UTF-8">
<title>KBEngine - Keywords</title>
<link href="style.css" rel="stylesheet" type="text/css">
</head>

<body>
<table width="100%" border="0" cellpadding="0" cellspacing="0">
<tr><td align=left style="background:#708090"> <font size=15 color=#ffffff> KBEngine </font></td></tr>
</table> <hr>

<h1>Keywords Used</h1>
<br></br>

<a name="EntityCall"></a><p class="function_definition">
<span class="function_definition">EntityCall:</span>
</p>

<div class="function_description">
<br><br>
This is the conventional means of remote interaction between entities in
the script layer. (other references: <a href=cellapp/Classes/Entity.html#allClients>allClients</a>,
<a href=cellapp/Classes/Entity.html#otherClients>otherClients</a>,
<a href=cellapp/Classes/Entity.html#clientEntity>clientEntity</a>).

<br><br>

The EntityCall object is very simple to implement in the underlying C++, it contains only the ID of the entity, 
the address of the destination, the entity type, and type of EntityCall.

When a remote call is requested by the user, 
the engine first finds a description of the entity definition through the entity type, 
and checks the data input by the user against the description of the entity definition. 
If the check is legal, then the data is packaged and sent to the destination 
according to the protocol.
<br><br>
Note: An EntityCall can only be used to call methods declared in its corresponding 
def file. It cannot call any of KBEngine's basic Entity class functions or 
access entity attributes.

<br><br>
An Entity can contain up to three parts:<br>
<b>Client</b>: When an entity includes a client part (usually a 
player), the entity's client (EntityCall) property can be accessed on the 
server side.<br>
<b>Base</b>: When an entity includes a baseapp part, the base (EntityCall) 
attribute of the entity can be accessed in a non-current baseapp.<br>
<b>Cell</b>: When an entity includes a cellapp part, the cell (EntityCall) 
attribute of the entity can be accessed in a non-current cellapp.<br>

<br>

Example:<br><br>
Client remote method defined in Avatar.def:
<pre>
	&lt;ClientMethods&gt;
		&lt;hello&gt;
		&lt;/hello&gt;
	&lt;/ClientMethods&gt;
</pre>

<br><br>
client\Avatar.py
<pre>
	class Avatar:
		def hello(self):
			print("hello")
</pre>
<br><br>

Enter in the Debug page input box of the GUIConsole tool (check the 
process to be debugged first in the list on the left):<br>
First find the ID of the player entity (Avatar) in the log of the server's
Baseapp, and then get the player entity (Avatar) or EntityCall through 
the entity ID:<br><br>

>>> KBEngine.entities[Player ID].client.hello()<br>
<br>
At this point, the client log file will output "hello" and a remote call
process will be completed.
</div>



<a name="KBE_ROOT"></a><p class="function_definition">
<span class="function_definition">KBE_ROOT:</span>
</p>

<div class="function_description">
<br><br>
This is a KBEngine environment variable that describes the root directory
where KBEngine is located.
</div>



<a name="KBE_RES_PATH"></a><p class="function_definition">
<span class="function_definition">KBE_RES_PATH:</span>
</p>

<div class="function_description">
<br><br>
This is a KBEngine environment variable that describes the resource 
directory that KBEngine engine can read.
</div>



<a name="KBE_HYBRID_PATH"></a><p class="function_definition">
<span class="function_definition">KBE_HYBRID_PATH:</span>
</p>

<div class="function_description">
<br><br>
This is a KBEngine environment variable that describes the directory 
where the KBEngine engine executable file is located.
</div>



<a name="entities.xml"></a><p class="function_definition">
<span class="function_definition">entities.xml:</span>
</p>

<div class="function_description">
<br><br>
All valid entity types on the server must be registered here. When the 
engine is initialized, the description of the entity is loaded according 
to the order.
</div>



<a name="kbengine_defaults.xml"></a><p class="function_definition">
<span class="function_definition">kbengine_defaults.xml:</span>
</p>

<div class="function_description">
<br><br>
Server-side default configuration, where users can modify all component
configurations such as <a href=cellapp/index.html>cellapp</a>, 
<a href=baseapp/index.html>baseapp</a>, and <a href=loginapp/index.html>loginapp</a>.

<br><br>
Note: You may often need to upgrade the engine. Modifying directly may 
cause conflicts during the upgrade, and it is not suitable for multiple 
projects in the same KBEngine environment.
<br><br>

It is recommended that you modify the overload in 
<a href=#kbengine.xml>kbengine.xml</a>. You only need to rewrite the 
parts you want to modify according to the format in xml.

</div>



<a name="kbengine.xml"></a><p class="function_definition">
<span class="function_definition">kbengine.xml:</span>
</p>

<div class="function_description">
<br><br>
Server configuration file, where users can modify all component configurations 
such as <a href=cellapp/index.html>cellapp</a>,
<a href=baseapp/index.html>baseapp</a>, and <a href=loginapp/index.html>loginapp</a>.<br>
For details, please refer to <a href=#kbengine_defaults.xml>kbengine_defaults.xml</a>
</div>



<a name="Entity"></a><p class="function_definition">
<span class="function_definition">entity</span>
</p>

<div class="function_description">
<br><br>
Entity is defined as the most basic object of the server, similar to 
Python's base object.<br>
When and how should you define an entity? See <a href=http://www.kbengine.org/docs/programming/entitydef.html>http://www.kbengine.org/docs/programming/entitydef.html</a>
</div>

<a name="View"></a><p class="function_definition">
<span class="function_definition">View</span>
</p>

<div class="function_description">
<br><br>
Each client entity connected to the server will have a View. It allows 
the client entity to communicate events in its View to its own client.<br>
View is related to space, and each View can be set to an independent size 
range.
<br><br>
Note: The space described here is an abstract concept and does not 
necessarily need to be bound to the concept of physical space (except
 for MMORPGs). For the core gameplay of a card game, players in a room can 
also be considered to be in a logical space.
<br><br>
Events include: entity movement, property change of client broadcast type, 
destruction on death, and so on.

</div>



<a name="Witness"></a><p class="function_definition">
<span class="function_definition">Witness</span>
</p>

<div class="function_description">
<br><br>
Eyewitness.<br> 
Only Witnesses bound to <a href=#cell>cell</a> entity Views take effect. 
In other words, Witness is a <a href=#cell>cell</a> proxy of the client. 
The cellapp continuously synchronizes the information in the View to the 
client through the Witness.<br>
When an NPC on the server is seen by a witness, it call the onWitness 
callback of the entity. The server can rely on this feature to reduce CPU 
consumption. When an entity is not witnessed, the server can stop any of 
its behavior.<br>
</div>


<a name="Space"></a><p class="function_definition">
<span class="function_definition">Space</span>
</p>

<div class="function_description">
<br><br>
A space KBEngine allocates on the cellapp, which is isolated 
from other spaces. Views, traps, entity collisions, etc. only interact with each 
other in the current space. The space is defined by the user. It can be 
a scene, copy, room...
</div>


<a name="cell"></a><p class="function_definition">
<span class="function_definition">cell</span>
</p>

<div class="function_description">
<br><br>
There are two different meanings of cell in this documentation. 
Usually, when referring to the <a href=baseapp/Classes/Entity.html#cell>Entity.cell</a> 
attribute, you are actually describing the entity's <a href=#EntityCall>CellEntityCall</a>.<br>
<br>
If a cell is described as part of a <a href=#Space>space</a>, it refers to <a href=cellapp/index.html>cellapp</a>'s load 
balancing technique. A space in the cellapp may be divided into n parts, 
each called a cell, and each cell is maintained by a different process.
<br>
</div>


<a name="base"></a><p class="function_definition">
<span class="function_definition">base</span>
</p>

<div class="function_description">
<br><br>
Usually refers to the Base entity on the <a href=baseapp/index.html>baseapp</a> 
or a <a href=#EntityCall>BaseEntityCall</a> that points to the Base entity.<br>
For example: <a href=cellapp/Classes/Entity.html#base>Entity.base</a>
</div>



<a name="client"></a><p class="function_definition">
<span class="function_definition">client</span>
</p>

<div class="function_description">
<br><br>
Usually refers to the client or an <a href=#EntityCall>EntityCall</a> 
that points to the client entity.<br>
For example: <a href=baseapp/Classes/Entity.html#client>Entity.client</a>
</div>



<a name="cellapp"></a><p class="function_definition">
<span class="function_definition">cellapp</span>
</p>

<div class="function_description">
<br><br>
The Cellapp process in mainly responsible for position-related game logic, 
View, AI, scene rooms, and so on.<br>
See also: <a href=cellapp/index.html>cellapp</a>
</div>


<a name="baseapp"></a><p class="function_definition">
<span class="function_definition">baseapp</span>
</p>

<div class="function_description">
<br><br>
The Baseapp process is mainly responsible for communication with the client, 
position-independent game logic (guild manager, chat system, game lobby, 
leaderboard, etc.), archiving, backup, and so on.<br>
See also: <a href=baseapp/index.html>baseapp</a>
</div>



<a name="real"></a><p class="function_definition">
<span class="function_definition">real</span>
</p>

<div class="function_description">
<br><br>
Refers to an entity in a cell that is actually present in the cell at that 
time. (As opposed to a <a href=#ghost>ghost</a> entity broadcast there by another cell)
</div>



<a name="ghost"></a><p class="function_definition">
<span class="function_definition">ghost</span>
</p>

<div class="function_description">
<br><br>
This kind of entity is a projected copy generated by cellapp's dynamic load 
balancing mechanism which divides a space into N shares and splits the cells
between different processes.<br>
Space is divided into multiple regions. To make the client unable to 
perceive the existence of the boundaries between them, we synchronize a 
certain range of entities in each cell's boundary to an adjacent cell's 
boundary. The entity has a part of its data synchronized over 
(CELL_PUBLIC, cell broadcast types of attributes) to a ghost entity. In 
this way the entity can interact seamlessly with the other side of the boundary 
and both cells simultaneously.
<br><br>
Non-ghost entities are called <a href=#real>real</a> entities.
</div>



<a name="vector3"></a><p class="function_definition">
<span class="function_definition">vector3</span>
</p>

<div class="function_description">
<br><br>

Describe and manage 3D space vectors. <br>
There are three properties of x, y, and z that represent different axial directions. <br><br>

Example in script: import Math v = Math.Vector3()
</div>



<br></br>
<br></br>
<br></br>
<br></br>
<hr></hr>

<p class="copyrightFooter">Copyright KBEngine</p>
</body>
</html>
